1
:link – Targets all unvisited links. These are links the user has not clicked on yet.
2
:visited – Targets links that the user has already visited. Browsers restrict the styles that can be applied to protect user privacy.
3
Use :link and :visited to visually differentiate unvisited and visited links for better navigation experience.

Example: :link vs :visited

In this example, links the user has not visited appear blue (:link), and links that have been visited appear purple (:visited). Hovering over any link changes its color and adds an underline.

Best Practices

1
Always use :link and :visited together to provide clear navigation cues.
2
Avoid using styles that violate privacy restrictions; only certain properties like color can be applied to :visited.
3
Combine with :hover and :active for consistent interactive feedback.
4
Test link styling across browsers as handling of visited links may vary.

Difficulty: 3/10

Topics: CSS pseudo-classes, link state styling, visual feedback

Scenario Questions

0-2 years experience

1
You're building a simple navigation bar and notice that all links look the same—even after clicking them. How would you fix it using :link and :visited?
2
A junior designer says they want visited links to turn red and bold. What’s the problem with that request, and how would you explain it?
3
What happens if you write a CSS rule for :visited but forget to define :link? Do the links still look different after being clicked?

2-5 years experience

1
Our users report that some links in the footer appear dim after clicking, but others don’t. You’ve checked the CSS—:visited is set, but it’s not working. What could be going wrong?
2
We’re building a documentation site with hundreds of internal links. Some teams are using :visited to indicate ‘read’ content, but accessibility audits are flagging it. How would you debug and fix this?
3
A feature flag turns on a custom theme that changes link colors. After the update, users say they can’t tell which links they’ve visited. What’s the most likely cause, and how do you verify it?

5-8 years experience

1
We’re designing a global navigation component used across 50+ micro-frontends. How do you ensure consistent :link and :visited behavior without breaking privacy restrictions or causing layout shifts?
2
Our analytics show users are clicking the same links repeatedly—could :visited styling be contributing to confusion? How would you redesign the feedback system to improve usability without violating browser security policies?
3
A legacy CSS file uses :visited to change background images. It’s causing performance issues and layout thrashing. How would you refactor this without losing the visual feedback users rely on?

8+ years experience

1
We’re migrating from a monolith to a component library, and legacy code relies on :visited for user progress tracking. How do you deprecate this safely without breaking user expectations or introducing privacy risks?
2
Our design system allows teams to customize link states. How do you enforce a policy around :visited styling that balances brand flexibility, accessibility, and browser security constraints across 200+ products?
3
A competitor uses :visited to track user behavior via CSS-based telemetry. How would you architect a privacy-compliant alternative that still provides engagement insights without exposing browsing history?

Follow-up Questions

❓What happens if you style :visited before :link?
❓Why can't you change the font size of a :visited link?
❓How would you test if your link styles are working correctly across browsers?